FIG. 1 is a block diagram illustrating non-limiting exemplary architecture of a distributed file system 100 implementing a Network Attached Storage (NAS) in accordance with the prior art. Distributed file server 120 may include a plurality of nodes (aka controllers) 130-1 to 130-x connected to a bus 180 operating in Internet Small Computer Systems Interface (iSCSI), a fiber channel (FC) or the like.
Bus 180 connects distributed file server 120 to a plurality of block storage devices 190 possibly configured as a part of a Storage Area Network (SAN) device aligned, for example, in a Redundant Array of Independent Disks (RAID) configuration.
Each of nodes 130-1 to 130-x may include a central processing unit (CPU) 160-1 to 160-x respectively, and memory units 150-1 to 150-x respectively, on which several processes are being executed. Nodes 130-1 to 130-x may communicate with a plurality of clients over network protocols such as Network File System (NFS) and Server Message Block (SMB).
Some of the processes running over nodes 130-1 to 130-x may include file system daemons (FSDs) 170-1 to 170-x. Each of nodes 130-1 to 130-x may include one or more FSDs which serve as containers for services and effectively control files in distributed file server 120.
Files in distributed file server 120 are distributed across FSDs 170-1 to 170-x and across nodes 130-1 to 130-x. Distributed file server 120 may also include file servers 140-1 to 140-x in at least one of nodes 130-1 to 130-x. Each of file servers 140-1 to 140-x may receive file system connect requests 112 from clients such as client machine 110.
Such client machine 110 may include, in a non-limiting example, Windows™ clients communicating over Server Message Block (SMB) protocol. Upon receiving such a connect request 112, file servers 140-1 to 140-x refer the requests to one of FSDs 170-1 to 170-x that holds the required file.
In accordance with the SMB protocol, each of FSDs 170-1 to 170-x may include an SMB server (not shown here) which is a process running on the node and configured to control the network communication in accordance with the SMB protocol. When a file is first requested by a client, for each client requesting a file, the SMB server allocates a unique persistent file handle associated with a specific client. The handle is an object which determines file name and other identifiers and the state which indicates the permissions of a specific client and other clients, and what other operations are the other clients are prevented from (aka share mode).
In SMB protocol, the handle serves as a mechanism allowing a specific client to establish or reestablish connection to a certain file after disconnection. In a case that SMB3 protocol is implemented, system failovers and/or node/FSD exchanges may be transparent to a client. That is, if connection with an FSD is lost, for example if a node or FSD fails or if the file server redirects a file to another node or FSD for better load balancing, the client may be reconnected to another node/FSD without interruption with the client's operations. In such cases, the persistent handle state must be preserved from the moment of connection loss and until client is reconnected again, for example to the other node/FSD.
FIG. 2 is a block diagram illustrating non-limiting exemplary architecture of a distributed file server system in accordance with the prior art. Distributed file server system 200 may include a plurality of nodes 210-0 and 210-1 and a storage disk 220. Each node may include a plurality of file system daemons (FSDs) 211-0 to 211-3 and 212 to 212-1 that control files in the distributed system. The files in the system are distributed across the FSDs and across the nodes of the system. The distributed system may also include a file server 230 in at least one of the nodes. The file server receives file system requests from clients such as, for example, Windows™ clients over Server Message Block 2.0 (SMB 2) protocol, such as SMB client 240 and refers the requests to the proper FSD that holds the required file.
For each client requesting a file, the file server allocates a unique persistent file handle associated with a specific client, i.e. a mechanism allowing a specific client to establish or reestablish connection to a certain file. Such persistent handle may have a unique identity (ID) across the entire distributed system, thus allowing a client to establish or reestablish connection with the file via any of the nodes and to resume its work with previously allocated handle, by including the unique handle ID with the connection request. The unique ID is provided to the client by the file server upon creation of the handle. Once receiving client's request including the unique ID, the server may locate the handle state of the respective handle and may allow the client to resume connection with the file.
In order to reconnect, the file server has to locate the corresponding file handle state, i.e. validate the handle state keys. If all validations are accomplished successfully, the file server may allow the client to resume its connection to the file. In order to perform the validations of the file handle state required for reconnection, the file server receives several data keys, including the file name, the persistent handle state identifier and globally unique identifiers (GUIDs).
By using these data keys, the file server can look up the file. However, in case the file name was changed, for example, during the time in which the handle was disconnected from the client, the looking up would fail because the file server received the previous file name as a key. Therefore, in case the file server relies on the file name in order to perform reconnection, it has to prohibit rename operation on file with disconnected file handles. Alternatively, the file can keep the original file name data as a look up parameter so that the server can find him also based on the original file name.
Implementations of several vendors require the file name within the reconnect request in order to perform reconnection of persistent handles, as described above. For example, scale out file server of Windows Server™ 2012 relies on a file name provided with reconnection request. If a wrong file name is provided, or the file name is not provided at all, the server replies that the file looking up has failed. Additionally, the scale out file server of Windows Server™ 2012 does not allow renaming of files when a disconnected persistent handle exists.